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REMARKS 

After entry of the above amendments, 21-38 will be pending in the present application. 
Claims 1-20 have been cancelled. New claims 21-38 have been added. Support for the new 
claims can be found, for instance, in the claims as originally filed and in the specification. 
Applicant reserves the right to pursue any of the cancelled claims in a continuation application. 
No new matter has been added. 

$ 101 /$ 112 Rejections 

Previously pending claims 1-7 were rejected under 35 U.S.C. §§ 101 and 112. The Office 
action states: 

Claims 1-7 are rejected under 35 U.S.C. 101 because the claimed 
invention is directed to non-statutory subject matter. Lacking any specification in 
the disclosure the term "computer readable medium" is sufficiently broad as to 
include the non-statutory subject area of signals embodied in a transmission 
medium. 

(April 21, 2006 Office action, pg. 3). The Office action also states: 

Claims 1-7 are rejected under 35 U.S.C. 112, second paragraph, as being 
indefinite for failing to particularly point out and distinctly claim the subject 
matter which applicant regards as the invention. Claims 1-7 recite the limitation a 
"computer readable medium," yet this term does not have any basis in the 
specification. 

(April 21, 2006 Office action, pg. 2) 

Applicant respectfully disagrees with the Office action's assertions that the term 
"computer readable medium" needs to be taught in the specification. One of skill in the art will 
readily understand the meaning and scope of the term "computer readable medium." Further, 
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"computer readable medium" claims are recognized as an accepted type of claim, similar to 

"method," "system," and "device" claims. Specifically, MPEP § 2106 states: 

[A] claimed computer-readable medium encoded with a computer program is a 
computer element which defines structural and functional interrelationships 
between the computer program and the rest of the computer which permit the 
computer program's functionality to be realized, and is thus statutory. 

(M.P.E.P. § 2106.IV.B.l(a), 8 ,h ed„ 4 th rev.) 

Therefore, based at least on the reasons above, Applicant respectfully submits that new 
claims 27-32, which recite a "computer readable medium including a computer readable program 
for preserving an original schema of a table comprising a plurality of rows," are directed to 
statutory subject matter under 35 U.S.C. § 101 and satisfy the requirements under 35 U.S.C. 
§112. 

§ 102 Rejections 

Previously pending claims 1-20 were rejected under 35 U.S.C. § 102(b) as being 
anticipated by the public use or sale of Oracle 8i. 

New claim 21 recites "making each of the one or more inserted or updated rows a self- 
describing row by storing metadata describing the new schema in the row." The Office action 
states: 

Claim 5 is anticipated by Oracle 8i as in claim 4, further including: e) 
updating row in the table; and f) converting the updated row into a self-describing 
row, wherein the table definition defined by a most recent schema change is stored 
in metadata associated with the updated row in the table (Oracle 8i Backup and 
Recovery Guide, chapter 3, page 15, § Perform Backups Frequently and 
Regularly, 1f 1, bullet 3]). 

(April 21, 2006 Office action, pgs. 4-5). 
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The cited passage of the Oracle 8i Backup and Recovery Guide states: 

Frequent backups are essential for any recovery scheme. Base the 
frequency of backups on the rate or frequency of database changes such as: 

• Addition and deletion of tables. 

• Insertions and deletions of rows in existing tables. 

• Updates to data within tables. 

If users generate a significant amount of DML, database backup frequency 
should be proportionally high. Alternatively, if a database is mainly read-only, 
and updates are issued only infrequently, you can backup the database less 
frequently. 

Use either Recovery Manager or O/S methods to create backup scripts. 
RMAN scripts, which are stored in the recovery catalog, are an especially efficient 
method for performing routine, repetitive backup operations. 

(Oracle 8i Backup and Recovery Guide, ch. 3, pg. 15). 

As seen from above, there is no mention of making a row into a "self-describing row," as 
recited in claim 21 or previously pending claim 5. In fact, the term "self-describing row" cannot 
be found anywhere in the passage. Further, there is no mention of storing metadata describing 
the schema of a row in the row. 

Therefore, based at least on the reasons above, Applicant respectfully submits that claim 
21, and the claims that depend therefrom, are not anticipated by the public use or sale of Oracle 
8i. Since claims 27 and 33 each recites elements similar to those of claim 21, it is respectfully 
submitted that those claims, and the claims that depend therefrom, are not anticipated by the 
public use or sale of Oracle 8i for at least the same reasons. 

New claim 22, which depends from claim 21, recites "rebuilding the table using a valid 
backup copy of the table, wherein, when a row of the valid backup copy is self-describing, 
metadata stored in the row is used to rebuild a corresponding row of the table and wherein, when 
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the row of the valid backup copy is not self-describing, the original schema stored in the 

designated table is used to rebuild the corresponding row of the table." The Office action states: 

Claim 6 is anticipated by Oracle 8i as in claim 5, further including: g) 
rebuilding the table during a data recovery process by gl) utilizing a valid backup 
copy of the table ([Oracle 8i Concepts, chapter 32, pages 5-6, § Database 
Backups]); g2) applying the original table schema stored in the designated table to 
a row in the valid backup copy of the table if the row is not a self-describing row 
(Oracle 8i Concepts, chapter 32, page 7, § Control Files]); and g3) applying the 
table definition stored in the metadata associated with the row if the row is a 
self-describing row ([Oracle 8i Concepts, chapter 32 [sic], page 41, § Application 
of Incremental Backups and Redo Records, f 1] if the incremental backup is 
found then all necessary metadata is present). 

(April 21, 2006 Office action, pg. 5). 

The first passage cited by the Office action states: 

A database backup consists of backups of the physical files (all datafiles 
and a control file) that constitutes an Oracle database. To begin media recovery 
after a media failure, Oracle uses file backups to restore damaged datafiles or 
control files. Replacing a current, possibly damaged, copy of a database file, 
tablespace, or database with a backup copy is called restoring that portion of the 
database. 

Oracle offers several options in performing database backups, including 

• Recoveiy Manager 

• operating system utilities 

• Export utility 

• Enterprise Backup utility 

(Oracle 8i Concepts, ch. 32, pgs. 5-6). 

The second passage cited by the Office action states: 

In general, the control file(s) of a database store the status of the physical 
structure of the database. Certain status information in the control file (for 
example, the current online redo log file, the names of the datafiles, and so on) 
guides Oracle during instance or media recovery, 

(Oracle 8i Concepts, ch. 32, pg. 7). 
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The third passage cited by the Office action states: 

If RMAN has a choice between applying an incremental backup or 
applying redo to the restored datafiles, then it always chooses to use the 
incremental backup. If over-lapping levels of incremental backup are available, 
then RMAN automatically chooses the one covering the longest period of time. 

If RMAN cannot find an incremental backup, it looks for an archived redo 
log. Whenever ARCw archives a redo log, Oracle immediately records it in the 
control file. Recovery Manager propagates that information into the recovery 
catalog during ^synchronization, classifying archived redo logs as image copies. 
Use the list command to display them. 

During recovery, RMAN looks for the appropriate archived redo logs in 
the default locations specified in the parameter file. If it cannot find them 
anywhere on disk, it looks in backup sets and restores archived redo logs as 
needed to perform the media recovery. 

By default, RMAN restores the archived redo logs to the current log 
archive destination specified in the init.ora file. Use the set archivelog destination 
command to specify a different restore location. 

(Oracle 8i Backup and Recovery Guide, ch. 4, pgs. 41-42). 

Although the above cited passages discuss data recovery, they do not disclose, teach, or 
suggest, differentiating between "self-describing" and "not self-describing" rows to decide 
between using metadata stored in a row or original schema stored in a designated table to rebuild 
the table. In addition, as with the other passage cited in the Office action, the terms "self- 
describing" and "metadata" cannot be found anywhere. Hence, Applicant respectfully disagrees 
with the Office action summarily concluding that "if the incremental backup is found then all 
necessary metadata is present." 



Further, Applicant respectfully submits that the issue is not whether metadata is present, 
but where the metadata is located. The passages relating to Oracle 8i cited by the Office action 
do not disclose, teach, or suggest that the metadata describing the schema of a row is stored in 
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Therefore, based at least on the additional reasons above, Applicant respectfully submits 
that claim 22, and the claims that depend therefrom, are further not anticipated by the public use 
or sale of Oracle 8i. Since claims 28 and 34 each recites elements similar to those of claim 22, it 
is respectfully submitted that those claims, and the claims that depend therefrom, are further not 
anticipated by the public use or sale of Oracle 8i for at least the same reasons. 

New claim 24, which depends from claim 21, recites "removing the original schema of 

the table from the designated table responsive to all of the rows in the table being 

self-describing." The Office action states: 

Claim 7 is anticipated by Oracle 8i as in claim 3, further including: d) 
removing from the designated table the original table schema for the table if each 
row in the table is self-describing ([Oracle 8i Backup and Recovery Guide, 
chapter 4, page 18, § Reports on Backups, Copies, and Database Schema, U 3]). 

(April 21, 2006 Office action, pg. 5). 

The cited passage states: 

The report command lists backup sets and datafile copies that can be 
deleted either because they are redundant or because they are unrecoverable. A 
datafile is considered unrecoverable if an unrecoverable operation has been 
performed against an object residing in the datafile subsequent to the last backup 

(Oracle 8i Backup and Recovery Guide, ch. 4, pg. 18). 

The passage, however, only generally discusses deletion of datafiles. It does not disclose, 
teach, or suggest removing a schema in response to "all of the rows in the table being 
self-describing," as recited in claim 24. As with the previous cited passages, there is no mention 
of "self-describing" rows anywhere. 
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Accordingly, based at least on the additional reasons above, Applicant respectfully 
submits that claim 24 is further not anticipated by the public use or sale of Oracle 8i, Since 
claims 30 and 36 each recites elements similar to those of claim 24, it is respectfully submitted 
that those claims are further not anticipated by the public use or sale of Oracle 8i for at least the 
same reasons. 



On the basis of the above remarks, reconsideration and allowance of the claims is 
believed to be warranted and such action is respectfully requested. If the Examiner has any 
questions or comments, the Examiner is respectfully requested to contact the undersigned at the 
number listed below. 



CONCLUSION 



Respectfully submitted, 
SAWYER LAW GROUP LLP 



Dated: 



July 17, 2006 




Erin C. Ming 
Attorney for Applicant 
Reg. No. 47,797 
(650) 475-1449 
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